is this just a cleanup as it was never in the public API or did it change between versions?

is this just a cleanup as it was never in the public API or did it change between versions?

It is an ABI-breaking change.
The disjoint pool uses this function. But before @bratpiorka implemented the disjoint pool in C, the disjoint pool was a static library (not part of libumf.so) that is why libumf.so exported this function. I expect the compatibility test to fail for this PR.

We agreed to work on API cleanup for version 0.12x, and if we succeed, this could become our UMF 1.0. So this change is correct, but we should also update our compatibility workflows. We need to discuss what we want to achieve and probably update the tags in the compatibility workflows to 0.11-dev3 (this is the first tag with a disjoint pool in C).

@ldorau could you set this PR to draft?

Converted to draft

1. Changing disjointpool from separate library to be part of libumf, was in fact API-braking change. This patch is just followup related to previous, change.
2. This is our miss take, we should NEVER export internal functions from the library, so good that we are fixing it now.
3. We decided that after 0.11 release we will do all braking changes, as preparation to 1.0 - so it's perfect time to fix problems like this.

As part of API/ABI stabilization, I suggest introducing ABI testing as part of compatibility testing to explicitly detect when when our ABI is changing. I like what LLVM compiler does for that (See this for more information). And this is the LLVM rules to maintain stable API/ABI. I think we should follow the similar rules.

Replaced by #1235